First draft of feature-netapp-trident #95
Conversation
rbo
force-pushed
the
feature-netapp-trident
branch
from
2d9d5c9 to
f3af9f1
Compare
| - name: iscsi.service | ||
| enabled: true | ||
| - name: multipathd.service | ||
| enabled: true |
There was a problem hiding this comment.
On SNO clusters, would this cause a reboot? Then subsequent operations might fail due to the API going down? Maybe wait for the pool to stabilize? Example for that is here:
https://github.com/DanielFroehlich/stormshift-automation/blob/4c216034ef72e5733a1dfabd188f85ac75276a6b/roles/feature-workload-partitioning/tasks/post-deploy.yaml#L32
There was a problem hiding this comment.
Uf that's not so easy / time consuming. Because If have to patch master, wait... patch worker, wait...
| backendType: "ontap-nas" | ||
| provisioningType: "thin" | ||
| snapshots: "true" | ||
|
|
There was a problem hiding this comment.
Maybe add some wait task here for everything to stabilize and be ready? I could image that this feature is one of the first in the sequence, because subsequent feature like RHOAI need storage, and it would be nice if those then do not fail. Eg. wait for the operator pod to be ready, or some of the Trident CRs maybe report a nice status we could wait for to be reached?
rbo
force-pushed
the
feature-netapp-trident
branch
from
f3af9f1 to
d7b3c13
Compare
rbo
force-pushed
the
feature-netapp-trident
branch
from
d7b3c13 to
5c3d436
Compare
rbo
force-pushed
the
feature-netapp-trident
branch
from
0c962ae to
862a4c4
Compare
#93